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(57) Abstract: A method for issuing an electronic identity based on previously certified electronic identity. This is accomplished 
by providing a method to use a previously certified identity to create another repre-sentational form for the same identity. This way 
the holder of a certificate can extend his or her already verified identity for other uses. The previously certified identity can be for 
instance so called mobile identity which is associated to a person's mobile ter-minal such as mobile phone. The person can show to 
certificate be his/her own by using the digital signature feature of the mobile terminal. 
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METHOD FOR ISSUING AN ELECTRONIC IDENTITY 

BACKGROUND OF THE INVENTION 

5 Field of the invention 

The present invention relates to electronic 
identity techniques and methods. More particularly the 
present invention relates j to a novel and improved 
10 method and system for requesting and issuing an elec- 
tronic identity based on; previously certified elec- 
tronic identity. 



15 



Description of the Prior Art 



With respect to securing communication, enti- 

electronically authenticate 



ties are often required to 

themselves before utilizing services or executing 
: transactions . This authenticity may come in the form of 
20 a username and password corflbination or a certificate. 

To accomplish this feat, tlpse entities must first reg- 
ister their existence either physically or virtually so 
that they might receive a R||oof of identity. 

Providing the proof , such as a username and 
25 password combination, carries out the actual authenti- 
cation. I Aforementioned simple authentication schemes 
are unfortunately quite context specific : identity 
based oh username and password may be totally insig- 
nificant in all other circumstances • Moreover, such 
30 proof does not irrefutably! distinguish different enti- 
• ■ tieis;. : ; : : . 

Electronic identities certified by digital 
certificates are used to Uniquely identify people and 
resources over networks sii|h as the Internet . With help 
35 of digital certificates itfj is possible to make secure, 
confidential ; communication between two parties. When 
one travels to another country, his/her passport pro- 
vides a universal way to ! establish your identity and 
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gain entry. Digital certificates provide similar iden- 
tification. Certificates may be issued by a trusted 
third party (TTP) such as a Certification Authority 
(CA) . Much like the role j^E the passport office, the 
5 role of the trusted third party is to validate the cer- 
tificate holders' identity and to "sign" the certifi- 
cate so that it cannot be forged or tampered with. Once 
a TTP has signed a certificate, the holder can present 
their certificate to people, Web sites, and network re- 

10 sources to prove their identity and establish en- 
crypted, confidential communications . 

M A certificate typically includes a variety of 
information pertaining to i|s owner and to the TTP that 
issued it. This information can be as follows. The name 

15 of the holder and other identification information re- 
quired to uniquely identify 



the holder, such as the URL 



of the Web server using tfre certificate, an individ- 
ual's email address or tn| holder • s public key. The 
public key can be used to encrypt sensitive information 

20 for the certificate holder |j the name of the Certifica- 
tion Authority that issued the certificate; a unique 
identifier; the validity period (or lifetime) of the 
certificate (a start and an end date) . 

In creating the certificate, this information 

25 is digitally signed by the issuing TTP. The TTP' s sig- 
nature on the certificate is like a tamper-detection 
seal on a bottle of pills -i ; any tampering with the con- 
tents is easily detected. Digital certificates are usu- 
1 ally based on public -key -cryptography, which uses a 

30 pair of keys for encryption and decryption. With pub- 
lic-key cryptography, keys work in pairs of matched 
"public" ! and "private " ke^| . In cryptographic systems , 
the term key refers to a numerical value used by an al- 
gorithm to alter information, making that information 

35 secure and visible only to individuals who have the 
corre sponding key to recover the information. 

The public key call be freely distributed with- 
out compromising the private key, which must be kept 
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secret by its owner. Since these keys only work as a 
pair, an operation (for example encryption) done with 
the public key can only be undone (decrypted) with the 
corresponding private key, land vice-versa. A digital 
5 certificate securely binds your identity, as verified 
by a trusted third party (a , with your public key. 

A CA certificate i| a certificate that identi- 
fies a Certification Authority. CA certificates are 
just like other digital certificates except that they 

10 are self -signed. CA certificates are used to determine 
whether to trust certificates issued by the CA. 

In the case of a passport, a passport control 
officer will verify the validity and authenticity of 
your passport and determine whether to permit you en- 

15 try- Similarly, the CA certificate is used to authenti- 
cate and validate the Web server certificate. When a 
Web server certificate is presented to a browser, the 
browser uses the CA certificate to determine whether to 
trust the Web server's certificate. If the server cer- 

20 tificate is valid, the secure session proceeds. If the 
server certificate is not v^lid, the server certificate 
is rejected and the secure session is stopped. 

In digital environment the contemporary 
equivalent of an identity card is a certificate: a con- 

25 firmed proof of an entity's distinct identity. A cer- 
tificate typically does morf than just confirms attrib- 
utes of its subject. The most common use of (public 
key) certificates is to bind an entity's public keys to 
its identity. These keys ;|an be used to various pur- 

30 poses such as providing authentication, authorization, 
confidentiality, integrity, ; or non- repudiation. 

Theoretically certificates are not context 
specific but in practice different uses require differ- 
ent certificates. E.g. standard X.509 certificate does 

35 not include e-mail address f information that is required 
in secure electronic mail !i (e.g. PGP or S/MIME) . Simi- 
larly other applications may need to have their own 
proprietary attributes included in certificates. Al- 
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though this inclusion of attributes is not problematic 
per se, however, new certificates need to be created. 

US patent 5, 982, 898 describes a method for is- 
suing a short term certificate for a person who already 
5 has a previous certificate. The new certificate is is- 
sued after the validation process of the ownership of 
the previous certificate. The validation is done by 
separating the tasks of identity verification and cer- 
tificate issuing, which allows a disassociating of the 

10 long-term binding between the person and his/her pub- 
lic/private key pair. This is accomplished by a regis- 
tration authority issuing a password to the person once 
it is | satisfied of person's bona fide. Thereafter, 
whenever the person wishes |o have a new certificate or 

15 electronic identity, the person contacts a certifica- 
tion authority, identifies itself with the password and 
obtains a certificate. The certificate typically in- 
cludes person' s name and a public key in plaintext, and 
a signature . The signature is derived by hashing the 

2 0 plaintext portion of the certificate to obtain a value, 
and encrypting the value with the CA's private key. 

In order to get $ certificate or some other 
electronic proof of identity a subject must prove and 
register its existence to eome authority. If the same 

25 identity needs several proofs for different uses, this 
repeated registration procedure would become quite in- 
convenient • 

SUMMARY OF THE INVENTION 

30 

This invention relates to a method for issuing 
an electronic identity, the' purpose of which is speci- 
fied above, for an entity from an identity registration 
authority. At first in the inventive method is issued a 
35 first electronic identity for said entity. The first 
identity is used as a "bAse" identity while issuing 
further identities. The method of issuing further com- 
prises the following steps of creating a request for a 
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second electronic identity for said entity, the request 
including an identifier of said entity, sending said 
request to said identity registration authority and in 
response to said request, creating an identification 
5 response. The request for issuing said second certifi- 
cate for said entity can also be initiated by said 
third party. 

Said identification response is sent to said 
entity which has initiated the request for the second 

10 electronic identity and an acceptability of said iden- 
tification response is verified by said entity. In re- 
sponse said verifying, if said identification response 
is acceptable, said entity digitally signs said identi- 
fication response. The sighing procedure can also be 

15 made by a second entity thlt is in possession of said 
first entity. The second entity can be one of the fol- 
lowing set including mobile terminal, mobile phone, 
personal computer, set -top box, smart card, tamper 
proof device, security token, software agent, pager, 

2 0 terminal equipment, and personal digital assistant 
(PDA) . Said signed response is sent to said identity 
registration authority which verifies a validity of 
said digital signature and said identification response 
in said signed response. In response to said verifying, 

25 if said digital signature and identification response 
are valid, said authority issues a second identity 
based on said first identity. Issuing of said second 
electronic identity could be canceled if said confirma- 
tion response is not received in a predetermined time 

30 period. 

Afterwards said issued second identity is 
stored to the database of said identity registration 
authority. Also it is possible to combine said first 
and said second electronic identities to form a com- 
35 bined electronic identity and to store said combined 
electronic identity to the database. Said issued second 
identity is sent to said eritity. If requested, said is- 
sued second identity can be sent to a third party. 
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In one embodiment of the invention it is 
checked if the information of said second entity is 
available using said identifier and in response said 
checking, if said information is not available, inquir- 
5 ing the information of sa^d second entity from said 
first entity. Advantageously; information of said second 
entity comprises one or more from the set containing a 
unique address of said second entity, the name of the 
holder of said second entity and previous identity or 

10 identities of said second entity. 

In one embodiment of the invention a communi- 
cation channel is established and encrypted between 
said first entity and said identity registration 
authority to ensure confidential communication there 

15 between. 

For further security, before the step of issu- 
ing said second identity, a check could be made if ad- 
ditional guarantees for ensuring a validity of the 
first identity are to be acquired. In response to said 

20 checking, if additional guarantees are needed, these 
additional guarantees can be acquired for instance from 
said first identity or trusted third party. 

In one embodiment of the invention a time 
stamp and/or a notarization could be added to said is- 

25 sued second identity. The time stamped second identity 
is stored to the database of said registration author- 
ity. Also into said time stamp could be added an expi- 
ration date of said second electronic identity. Also 
can be added to said issued second identity and 

30 In one embodiment of the invention a further 

identifier code could be inquired to be added into said 
signed identification response . The identifier code is 
received at said registration authority, wherein the 
validity of said identifier code is verified. The iden- 

3 5 tifier code can a biometrics code of said first entity, 
a predetermined character string, a fingerprint of the 
entity's public key, random number, certificate, or a 
hash code of the shared secret between said first en- 
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tity and said registration authority. It is also possi- 
ble to journalize a log of all transactions during the 
issue process of said second electronic identity. 

The purpose of this invention is to provide 
5 means to use a previously certified identity to create 
another representational form for the same identity. 
This representational form pan be expressed as an elec- 
tronic identity, a certificate, or a certificated ac- 
cess to a service or a server . This way an entity, 

10 which can be defined as a recipient of an electronic 
identity or a certificate or a holder of a certificate, 
can extend his, her or it0 already verified identity 
for other uses. The previously certified identity can 
be for instance so called mobile identity, which is as- 

15 sociated to a person's mobile terminal such as mobile 
phone. The person can show to certificate be his/her 
own by using the digital signature feature of the mo- 
bile terminal . 

In the following if an example of the steps of 

20 the identity extension process according to the present 
invention. Note that the entities and devices in the 
process description are listed by their role and may 
not be distinct ones in practical implementations. 

An entity needs to be authenticated in a con- 

25 text where it does not have a previously confirmed 
identity. The entity or authorized representative sup- 
plies optional information that is appended to verified 
facts provided by registration authority that knows the 
entity's mobile identity. 

30 This information and an identification request 

is sent to the mobile identity registration authority 
with routing info to the receiver of identification and 
also to the terminal equipment that contains the means, 
i.e. signing keys to prove the previously confirmed mo- 

35 bile identity. Based on identification request type 
registration authority appends optional sender- supplied 
attributes to verified data that it possesses and for- 
wards these to the specified terminal equipment. If the 
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identity cannot be resolved from the terminal routing 
info, the process terminates. 

The entity or authorized representative in- 
spects the accuracy of identification response informa- 
5 tion on the terminal equipment and if he, she, or it is 
satisfied with it, digitally signs the response after 
which it is sent back to registration authority. If 
identification type requires additional guarantees, 
e.g. certification, registration authority acquires ap- 
10 propriate confirmation from providers of those serv- 
ices. Confirmed identity information is sent to the re- 
ceiver address specified in the original identification 
request • 

Compared to previous registration and cert if i- 

15 cation schemes the most obvious benefit is that the 
present invention offers the same amount of trust that 
a local registration office is capable of providing 
without its physical and other constraints. The equiva- 
lence of trust holds on condition that the registration 

20 authority possesses or has access to corresponding in- 
formation, i.e. its private databases or databases of 
other authorities such as Finnish Population Registry 
Center. On the other hand there are also attributes, 
such as access to a certain e-mail address, that can be 

25 confirmed by virtual means even if these are not re- 
corded in advance. 

If mobile identity and equipment is used in- 
stead of e.g. a terminal equipped with a smart card 
reader, the solution of the present invention is to- 

30 tally location independent. An entity can confirm its 
identity and acquire a new identity whenever and wher- 
ever it is required and is not constrained by the 
available hardware and software provided that the re- 
cipient is capable of receiving the affirmation. Al- 

35 though the solution does not disallow the use of public 
mobile terminals (i.e. somebody else's phone), most 
likely the terminal that is used in authorizing the 
identification response is an entity's own. Conse- 
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quently an entity is not required to perform sensitive 
operations, such as entering a signing PIN, on dis- 
trusted devices. 

Essentially the invention is intended for ex- 
5 tending an entity's identity based on an existing mo- 
bile certificate and other verified and confirmed 
facts. The one of the most apparent and practical func- 
tions is to use this information to issue new certifi- 
cates for various uses such as secure e-mail, PGP or 
10 S/MIME. The mobile variant of the solution, however, 
does not have to be as limited. Since the ability to 
provide confirmed facts about an entity is totally mo- 
bile, in certain situations certificates are not a key 
issue. Say, if mobile identity registration authority 
15 has access to Finnish Population Registry Center's da- 
tabase it can provide confirmed home address, marital 
status, or whatever is required. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The features, objects, and advantages of the 
present invention will become more apparent from the 
detailed description set forth below when taken in con- 
junction with the drawings wherein: 

FIG. 1 is a block diagram of a system of the 
present invent ion ; 

FIG. 2 is a flow diagram in accordance with 
one embodiment of the invention; 

FIG. 3 is a second flow diagram in accordance 
with one embodiment of the invention 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Figure 1 presents one example of the preferred 
35 system according to the present invention. The system 
of figure 1 includes mobile station MS, which is con- 
nected through the communication network CN to the Cer- 
tificate Authority CA server. Also the system includes 



20 



25 



30 
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a terminal including for instance a web browser. The 
terminal is connected through the communication network 
CN to the server of CA. Also the system of figure 1 
comprises a service provider's server or other equiva- 
5 lent equipment SERVICE, which is connected to the com- 
munication network CN. This service can be for instance 
an e-mail service, which is provided via the communica- 
tion network CN. The mobile station contains means for 
digital signing a message or character string. Digital 

10 signing means are certified with at least one certifi- 
cate, which enables the user to authenticate more cer- 
tificates. This previous certificate can be a mobile 
certificate, which is mentioned above. 

Referring further to figure 1 it is described 

15 one preferred solution of the present invention. This 
solution is described in the context of certifying a 
new PGP key pair. 

In this solution the following assumptions are 
made. The mobile phone's SIM card-signed PGP key packet 

20 only "lives" for a short time (a few minutes) in the 
system and is then thrown away. If it is logged it can 
be used for journalizing the transactions in the issu- 
ing process . Also it can be logged perhaps for keeping 
track of errors. If there were to be any permanent re- 

25 tention of this packet (for legal or other purposes) , 
it would have to comply with some existing standard 
format, in order to be assured that it could be ac- 
cessed and correctly interpreted in the future. 

As described here, the format of the phone - 

30 signed PGP key packet does not fit any existing stan- 
dard. If necessary, a standard format could be de- 
signed, and the SIM card software would be required to 
create signatures in this format. The user has control 
(physical security) of the PC and corresponding PGP 

35 private key used for performing the operations de- 
scribed here. The CA operates a publicly accessible PGP 
keyserver containing all of the PGP keys that the CA 
has signed. 
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Here we describe the steps to follow in order 
to use the applicants Smart Signature system to securely 
sign a PGP key. SmartSignature is a Public Key Infra- 
structure on the SIM Card, which is assigned to the as- 
5 signee of the present invention. The PGP key is signed 
by the WPKI CA (WPKI, Wireless public key infrastruc- 
ture), using a user's SmartSignature SIM card to link 
the signature back to the proof of identity that was 
presented to the WPKI Local Registration Authority. 

10 This process is performed without breaching the anonym- 
ity of the user's SIM card Network ID (NID, Network 
Identifier) . As described here, the process is state- 
less on the CA end, reducing complexity and increasing 
resiliency of the protocol for the CA. 

15 At first software using PGP on the PC displays 

the name and PGP key fingerprint of the user that is to 
be certified on the PC screen. Also displayed on the PC 
display is a prompt to enter the 4 -digit number on the 
mobile phone display. 

2 0 The PGP key fingerprint is a cryptographically 

strong hash of the key. PGP users are accustomed to 
verifying keys by comparing key fingerprints, so this 
makes it easier to verify the PC-Phone link is reli- 
able, and not being attacked by an intruder inserting a 

25 fake message to be signed by the phone. The latter is 
probably not necessary to protect against, since we as- 
sume physical security for that link. However, the link 
is not necessarily secured. 

The PC software communicates with the phone 

30 through the wired or wireless interface or other appro- 
priate interface, and passes a message packet (TBD) 
containing a command to start the PGP key signing proc- 
ess. Phone generates and displays a four digit random 
number, along with a prompt to type this number into 

35 the PC if the user wants to sign his PGP key with his 
phone key. 

The phone displays a 4 digit random number 
that then must be manually entered into the PC's key- 
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board. This prevents a daring (high probability of de- 
tection) attack from a hostile device that might be 
communicating with the phone, and trying to trick it 
into signing a "What is my name?" message that could be 
5 used to compromise the NID's anonymity. 

Then user types in the 4 -digit number from the 
display on the phone into the PC, as requested by the 
screen prompt . 

On the PC, the software takes the 4 digit ran- 
10 dom number entered by the user, and sends it with a 
message, intended to be sent to the CA, requesting 
(from the CA) a User ID lookup for a phone NID that 
signed the request. In other words, a "What is my 
name? " request . 

15 The phone compares the random number sent with 

the "What is my name?" request, and if it matches, dis- 
plays a warning that it is about to sign a PGP key with 
its key. 

PC displays a lengthy legal notice to user, 
2 0 warning that user is about to sign their PGP key with 
the phone's key and that the user is contractually ob- 
ligated to only make this signature if he is the owner 
of both keys. Again, if the random number matched, the 
"What is my name?" message is signed by the phone, re- 

2 5 turned to the PC through the serial interface, and 

saved for transmission to the CA. The PC software gen- 
erates another message, intended for transmission to 
the CA, this message contains the key fingerprint, and 
a request to the CA to sign the attached key, if the 
30 fingerprint matches. This is a "Sign this User ID and 
key, please." request. The "Sign this User ID and key, 
please." message is then passed to the phone through 
the serial interface, with a request that the phone 
sign the packet, using the its SIM card private key. 

3 5 The PGP key fingerprint is displayed on the 

phone at this point and verified by the user to be in 
agreement with the PGP key fingerprint on the PC 
screen. The user is prompted to OK the signature, if 



WO 01/54346 



PCT/FI0 1/00052 



the fingerprint matches. The User's phone sends the 
signed "Sign this User ID and key, please." packet back 
through the serial interface to the PC [along with the 
phone key ID that signed it] . Save on the PC for later 
5 transmission to the CA. The PC-Phone connection is no 
longer needed after this point, and is dropped. 

Note that if desired, the process described in 
the preceding few steps could be accomplished with only 
one signed message from the phone. This message would 

10 contain a signature of the PGP key fingerprint. The one 
message would be used with two different meanings, 
first to ask the CA, "What's my User ID (name)?", and 
second to command it to "Sign this Key and User ID 
please". In the first case the PGP key fingerprint is 

15 ignored, since only the phone's NID is need to specify 
what name is desired from the CA. 

The PC opens up a secure channel (using TLS) 
to the Certification Authority. The PC sends the SIM- 
signed request for User ID ("What's my User ID and 

2 0 name?") query to the CA over the secure link. 

The CA looks up the phone's owner in the con- 
fidential database, and sends the User ID for the phone 
back to the PC, as requested. This is the WPKI User ID 
that the phone's owner had certified at the LRA. Send- 

2 5 ing this information to the PC does not breach the ano- 

nymity of the NID, since the link is encrypted and the 
phone owner is the one making the request. 

The PC checks to see if the returned WPKI User 
ID is present on the user's PGP key. If it is, then the 
30 process proceeds to the next step, automatically. If 
the returned WPKI User ID is not present on the PGP 
key, then the User ID is added to the PGP key before 
proceeding . 

If the WPKI User ID must be added to the PGP 

3 5 key, we branch off at this point and follow the normal 

PGP procedure for adding a new User ID to one's key- 
ring. The user must supply an email address for this 
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User ID, because the User ID supplied by the CA will 
not have an email address. 

Since the ultimate result of this process will 
be publication of the signed key on a public keyserver, 
5 the User ID must be self-signed. PGP User IDs are only 
suitable for publication if they are signed by the 
key's owner. 

The PC next uses the user's PGP private key to 
sign the "Sign this key, please." request to the CA 
10 (this request is asking the CA to sign the phone 
owner's PGP key, remember) . This request was signed 
earlier by the phone's SIM card. 

This signature shows the CA that the requestor 
is the one who controls the PGP private key component, 
15 and is not sending someone else's key for certifica- 
tion . 

The PC sends the PGP and Phone signed "Sign 
this User ID and Key, Please." request packet with the 
corresponding PGP key up to the CA, through the estab- 

2 0 lished TLS link. Again, this packet links the phone 

owner's (presumably anonymous) NID with the public PGP 
identity, so the channel must be encrypted. 

The CA checks the PGP signature. The CA checks 
the phone key. The CA then checks in its confidential 
25 database for the User ID associated with the phone that 
signed the "Sign this Key, Please." request. The sub- 
mitted PGP User ID (name portion) must match with the 
CA's phone's user name. This will be the case, because 
we just added the User ID returned by the CA for this 

3 0 NID to the PGP key we attached to the message. 

If the submitted User ID for this phone is not 
found in the CA's confidential database, the request is 
denied, and an error message is sent back to the PC. 
For debugging purposes, this error message could con- 
3 5 tain the correct User ID, since we are operating over 
an encrypted channel . The user is informed of the prob- 
lem via an error message displayed on PC. If the name 
portion of the User IDs match, then the CA signs the 
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PGP key with the CA key and discards the "Sign this 
key, Please" request with the phone NID. It then in- 
serts this information into the confidential database. 
The CA- signed PGP key is added to a "Pending PGP Cer- 
5 tificate" database on the CA. 

The CA then emails the CA- signed PGP Key to 
the email address specified by the user in the User ID 
that was signed by the CA. This provides a check that 
the email address is correct. This certificate is en- 
10 crypted by the public encryption key of that user. That 
way if the email address turns out to be wrong, and the 
key is misrouted, it will likely never be decrypted by 
anyone . 

The CA expects the user to decrypt and re- 
15 upload the signed key back up to the CA, thus proving 
that the email address was correct, and the person re- 
siding at that email address has the capability of de- 
crypting with that key. When the CA receives this key 
back from the user, the CA purges it from the Pending 
20 PGP Certificate database. To overcome email delivery 
problems, periodically the CA will repeat the previous 
step until the user responds or until the CA decides to 
give up . 

When the CA receives this key back from the 
25 user, the CA publishes the resultant signed PGP key on 
its PGP key server. The PGP key is signed only with the 
LRA-verif ied User ID, of course. None of the other 
UserlDs that the user might have on his PGP key are 
signed by the CA. Note also that the telephone NID is 
3 0 not part of the PGP key, nor is it published with the 
PGP key, so we are still protecting the user's NID- 
related anonymity. 

Figure 2 presents one example of the flowchart 
of the present invention. First the need for any addi- 
35 tional data is checked, state 21. The additional data 
can be user's current and previously issued certificate 
or some other information like the name or the e-mail 
address of the user. If any additional information is 
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needed then the user will provide it, state 22. Then 
the request for identification is sent to the registra- 
tion authority CA, state 23. According the identity in- 
formation the existence of any previous identities is 
5 searched, state 24. This search can be made in the pri- 
vate databases of the registration authority or data- 
bases of other authorities. If any previous identities 
is found then a response is created and sent to speci- 
fied terminal, state 26. If any previous identities is 

10 not found then the information needed is acquired from 
the user. If the user accepts the response he or she 
signs it digitally and sends it back to registration 
authority, states 27 and 28. If any additional guaran- 
tees are required then those can be acquired from ap- 

15 propriate authorities, states 2 9 and 210. Finally the 
confirmed identity information is sent to specified re- 
ceiver, state 211. 

Figure 3 presents one example of the certifi- 
cate of the present invention. The certificate contains 

2 0 a number of information, which are required for the 
identification. Typically such information are certifi- 
cate identification number, user name, users e-mail ad- 
dress, RSA/DSS keys, the fingerprint of the signature 
or of the certificate itself, the hash of the 

25 passphrase, the signature, and the expiration date of 
the certificate. 

The previous description of the preferred em- 
bodiments is provided to enable any person skilled in 
the art to make or use the present invention. The vari- 

30 ous modifications to these embodiments will be readily 
apparent to those skilled in the art, and the generic 
principles defined herein may be applied to other em- 
bodiments without the use of the inventive faculty. 
Thus, the present invention is not intended to be lim- 

35 ited to the embodiments shown herein but is to be ac- 
corded the widest scope consistent with the principles 
and novel features disclosed herein. 



WO 01/54346 



PCT/FI0 1/00052 



CLAIMS 

1. Method for issuing an electronic identity for 
an entity from an identity registration authority, the 
method comprising the steps of : 
5 a) issuing a first electronic identity for said 

entity; 

b) creating a request for a second electronic 
identity for said entity, the request including an 
identifier of said entity; 
10 c) sending said request to said identity regis- 

tration authority; 

d) in response to said request, creating an 
identification response; 

e) sending said identification response to said 

15 entity; 

f) verifying an acceptability of said identifi- 
cation response by said entity; 

g) in response said verifying, if said identifi- 
cation response is acceptable, signing digitally said 

20 identification response by said first entity; 

h) sending said signed response to said identity 
registration authority; 

i) verifying a validity of said digital signa- 
ture and said identification response in said signed 

2 5 response; and 

j) in response to said verifying, if said digi- 
tal signature and identification response are valid, 
issuing a second identity based on said first identity. 

2 . The method of claim 1 further comprising a 
30 second entity by which said first entity digitally 
signs said identification response. 

3 . The method of claim 1 or 2 further comprising 
the steps of : 

checking if the information of said second en- 
35 tity is available using said identifier; and 



WO 01/54346 



PCT/FI0 1/00052 



in response said checking, if said information 
is not available, inquiring the information of said 
second entity from said first entity. 

4. The method of claim 2 or 3 wherein said sec- 
5 ond entity is in control of said first entity. 

5. The method of claim 3 wherein said informa- 
tion of said second entity comprises one or more from 
the set containing a unique address of said second en- 
tity, the name of the holder of said second entity and 

10 previous identity or identities of said second entity. 

6. The method of claim 1 further comprising the 

step of : 

establishing and encrypting a communication 
channel between said first entity and said identity 
15 registration authority to ensure confidential communi- 
cation there between. 

7. The method of claim 1 further comprising the 

step of : 

storing said issued second identity to the data- 
20 base of said identity registration authority. 

8 . The method of claim 1 further comprising the 

step of : 

storing said issued second identity to the data- 
base of the issuer of said first electronic identity. 
25 9. The method of claim 1 further comprising the 

step of : 

combining said first and said second electronic 
identities to form a combined electronic identity; and 

storing said combined electronic identity to the 
3 0 database. 

10. The method of claim 1 further comprising the 

step of : 

sending said issued second identity to said en- 
tity. 

35 11. The method of claim 1 further comprising the 

step of : 
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sending said issued second identity to a third 

party. 

12. The method of claim 1 before the step of is- 
suing said second identity further comprising the steps 
5 of : 

checking if additional guarantees for ensuring a 
validity of the first identity are to be acquired; and 

in response to said checking, if additional 
guarantees are needed, acquiring additional guarantees. 
10 13 . The method of claim 1 further comprising the 

steps of : 

adding a time stamp to said issued second iden- 
tity; and 

storing said time stamped second identity to the 
15 database of said registration authority. 

14. The method of claim 1 further comprising the 

step of: 

adding into said time stamp a expiration date of 
said second electronic identity. 
20 15. The method of claim 1 further comprising the 

steps of : 

adding a notarization to said issued second 
identity; and 

storing said notarized second identity to the 
25 database of said registration authority. 

16. The method of claim 1 further comprising the 
steps of : 

inquiring a further identifier code to be added 
into said signed identification response 
30 receiving said identifier code at said registra- 

tion authority; and 

verifying the validity of said identifier code 
at said registration authority. 

17. The method of claim 16 wherein said identi- 
35 fier code includes one or more from the set containing 

biometric code of said first entity, a predetermined 
character string, a fingerprint of the entity's public 
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key, random number, certificate, and a hash code of the 
shared secret between said first entity and said regis- 
tration authority. 

18. The method of claim 1 further comprising the 
5 steps of : 

creating a first hash code from said identity 
request at registration authority; 

sending said first hash code to said second en- 
tity; 

10 creating a second hash code from said identity 

request by said second entity; and 

verifying a validity of said first hash code by 
comparing it to said second hash code before the sign- 
ing of said response . 

15 19. The method of claim 1 or 2 before the step 

of issuing further comprising the steps of: 

sending a confirmation message to the address 
specified in said additional information of said en- 
tity; 

20 receiving a confirmation response to said con- 

firmation message at said registration authority; and 

verifying the validity of said confirmation re- 
sponse . 

20. The method of claim 19 before the step of 
25 issuing further comprising the step of: 

canceling said issuing of said second electronic 
identity if said confirmation response is not received 
in a predetermined time period. 

21. The method of claim 1 wherein said request 
30 for issuing said second certificate for said entity is 

initiated by said third party. 

22 . The method of claim 1 wherein said request 
for issuing said second certificate for said entity is 
initiated by said second entity. 
35 23. The method of claim 2 wherein said request 

is digitally signed by said first entity before sending 
said request . 
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24. The method of claim 2 wherein said request 
is encrypted before sending said request . 

25. The method of claim 1 further comprising the 

step of: 

5 journalizing a log of all transactions during 

the issue process of said second electronic identity. 

26. The method of claim 2 wherein said second 
entity is one of the following set including mobile 
terminal, mobile phone, personal computer, set- top box, 

10 smart card, tamper proof device, security token, soft- 
ware agent, pager, terminal equipment, and personal 
digital assistant (PDA) . 
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